实践真知：一则因内存导致的集群故障
编辑手记：作为一个运维者，会遇到各种各样的故障，你不可能学会处理每一个故障，但如果你有了专家的思维，会分析问题，所有的困难便会迎刃而解。今天我们拣选一则经典故障分析与大家共享。
故障概述
某天晚上，我方收到行方请求协助分析某数据库两节点RAC数据库问题，问题描述如下：
该 数据库版本为11.2.0.3，该版本中ASM内存管理机制有所变化，导致ASM实例对共享内存的需求加大，由于该数据库ASM实例共享内存设置过小，导致ASM实例间歇性出现ORA-4031共享池无法分配连续内存空间。为解决该问题，行方决定调整ASM实例内存参数，而在首先修改节点2 ASM内存参数并重启节点2 grid集群过程中，发现节点1 grid集群状态异常，并且在重启节点2集群后，查看节点1 grid集群状态依然报错如下，但此时查看两节点数据库均可以正常访问，应用程序无异常。
另外，当节点2集群正常重启完成后，在节点1 grid集群状态由于ORA-4031错误，依然异常的情况下，出现节点2 vip 地址40.53.2.9同时出现在两个节点的现象如下，此时应用程序仍然无异常表现。
我方在接到服务请求后，通过全面收集相关日志信息进行分析诊断，给出如下诊断结果：
针对问题1诊断结果为：在修改节点2 ASM实例内存参数并重启节点2集群过程中，节点1 ASM实例遭遇严重的ORA-4031错误，导致节点1集群crsd进程异常终止，从而无法正常访问RAC集群配置文件voting及ocr所在的ASM磁盘组(datadg)。而在此过程中集群的crsd进程，曾多次尝试重启均由于ORA-4031问题而失败。经过分析判断后，在保证节点2存活的情况下，最终通过继续完成节点1ASM实例内存参数调整并重启节点1集群后恢复正常。
针对问题2诊断结果为：在节点2调整ASM实例内存参数并重启grid集群过程中，节点2 vip 40.53.2.9发生failover,该vip漂移至节点1，节点1正常接管节点2 vip 40.53.2.9后，由于节点1此时正遭遇严重的ORA-4031问题，导致接管后立刻再次进入failover状态，而此时节点2正处于重启过程中无法接管，导致节点2 VIP 40.53.2.9在节点1脱离集群管理，脱离集群管理后的资源不受cluster所管理，导致40.53.2.9一直出现在节点1上。而linux与windows不同，地址重复后并不会产生冲突，而是同时存在，此时应用客户端随机选取arp地址映射，学习到节点1的mac地址映射，就会使用节点1上的VIP，学习到节点2的mac地址映射，就会使用节点2上的VIP，而客户端配置了节点间的failover，所以此时就是连接了错误节点，仍然不影响应用程序正常运行。
故障分析
从节点2 alert_+ASM2.log日志中看到，12月7日 18:01:50在节点2修改ASM实例内存参数，并于18:04:33重启节点2 ASM实例。
节点2 alert_+ASM2.log日志摘录如下：
在节点2重启ASM实例过程中，节点1 alert_+ASM1.log日志中可以看到出现大量ORA-4031内存无法分配的错误：
节点1 alert_+ASM1.log日志摘录如下：
在文档概述部分我们看到：在节点2重启集群的过程中，节点1使用crsctl check crs查看集群状态，cssd进程及evmd进程处于正常的online状态，只有crs进程状态异常。
因此进一步观察节点1 crsd进程日志，可以看到在节点2重启集群的过程中，节点1由于ORA-4031错误导致导致ASM实例与存储OCR文件的ASM DATADG交互产生问题。
节点1 crsd.log日志信息摘录如下：
---此处省略大量由于ORA-4031错误导致读取OCRRAW出错的DUMP信息部分
---最终于18:04:48 CRSD异常终止
---crsd进程异常终止后尝试进行自动重启
---此处省略部分输出
---crsd尝试重启，由于无法正常打开集群重要的ocr和voting配置文件所在的磁盘组，最终crsd进程无法正常启动，此后不论是集群自动重试还是人工手动重启多次都以失败告终
以上从节点1 crsd日志看到crsd进程由于ASM实例的ORA-4031错误导致ASM实例与磁盘组之间的交互产生问题，那么我们进一步分析问题时段节点1grid集群alert_csrrac01.log同样可以看到ORA-4031错误导致crsd进程异常的现象。
节点1 grid 集群 alert_csrrac01.log日志摘录如下：
---此处记录了节点2修改ASM实例参数后，节点2人工重启grid集群
---crsd进程于18:04:48首次failed，这与节点1 crsd.log记录的首次失败时间吻合
---crsd异常终止的原因同样是由于无法正常访问OCR所在的物理存储
---此处省略部分类似输出
--节点1 crsd进程失败后，曾多次尝试重启，并最终达到尝试重启crsd进程次数
---节点1 crsd无法重启的原因依然是由于ORA-4031错误无法正常读取OCR所在物理存储，即: ASM datadg导致
最后，针对问题2，我们知道11g 集群在资源管理方面发生了很大改变，不同的资源通过不同的agent代理进行管理，而vip资源是通过orarootagent代理进行管理，进一步我们通过节点1的orarootagent_root.log可以发现如下信息：
节点1 grid 集群orarootagent_root.log日志摘录如下：
---由于节点2重启grid集群，导致节点1收到添加节点2 vip资源的信息
---此处省略部分输出
---尝试在节点1 igb0网络接口挂在节点2 vip 40.53.2.9
---节点2成功接管节点1vip 40.53.2.9
---由于此时节点1正遭遇严重的ORA-4031问题(见以上分析)，导致成功接管节点2 vip后，状态立即变化为非正常的PARTIAL状态
---节点2 vip资源再次进入failover状态，而此时由于节点2在进行集群重启操作，尝试failover无法成功，而又无法被节点1正常接管，导致节点2 vip在节点1上脱离集群管理，由于最初节点1成功接管过节点2 vip，即在igb0接口成功挂在40.53.2.9地址，此时又无法进行failover,导致脱离集群管理后的的40.53.2.9地址继续挂在在igb0接口之上。
故障总结
由于本次ASM内存参数调整，首先更改并重启节点2集群，在此过程中节点1 ASM实例遭遇严重的ORA-4031错误，导致CRSD进程异常，从而引发节点1集群状态异常。
问题发生时，节点2 ASM实例内存参数已修改完成并重启成功，因此，在实例2保持存活的情况下，立即将节点1 的ASM内存参数修改并重启后，集群状态恢复正常。
附录：11.2.0.3/4 ASM 内存管理变化
ASM实例需要的共享内存与processes及diskgroup多少直接相关，而在Oracle 11.2.0.3和11.2.0.4版本中缺省的processes算法发生变化如下：
因此ASM实例需要更大的内存空间提供支持，以避免出现ORA-4031问题。
在Oracle 11.2.0.3/11.2.0.4中如果ASM实例使用的内存小于1536M，将可能导致ASM内存实例遭遇ORA-4031问题，Oracle官方推荐的ASM实例内存参数配置如下：
---the end
精彩预告:
11月4日，Oracle技术嘉年华 - 国内规模最大的Oracle技术盛会将在京举行，美国OOW的最新信息将悉数来至中国，欢迎您来到大会现场。
主题：数据•技术•平台 - 新时代的技术前沿
大会网站：http://2016otn.31huiyi.com/
会议时间：2016年11月4日（周五）- 5日（周六）
会议地点：北京·富力万丽酒店
更多Oracle技术嘉年华相关信息请点击了解：2016 Oracle技术嘉年华。
如何加入"云和恩墨大讲堂"微信群
搜索 盖国强（Eygle）微信号：eyygle，或者扫描下面二维码，备注：云和恩墨大讲堂，即可入群。每周与千人共享免费技术分享，与讲师在线讨论。
关注本微信（OraNews）回复关键字获取
2016DTCC, 2016数据库大会PPT；
DBALife,"DBA的一天"精品海报大图；
12cArch,“Oracle 12c体系结构”精品海报；
DBA01，《Oracle DBA手记》第一本下载；
YunHe，“云和恩墨大讲堂”案例文档下载；